双十一｜探索KUN的加载性能与增强体验
双十一与Kun
关注闲鱼技术的同学想必都对Kun有所了解，Kun是闲鱼技术团队自研终端渲染容器，使用前端研发方式进行高效开发，最终以Flutter渲染给用户提供高性能体验。Kun已经在我发布的、闲鱼号、闲鱼超市等业务中使用，提供给用户良好的加载性能与独特的增强体验。一年一度的双十一要到了，我们也希望双十一能够应用Kun的加载性能与增强体验。而今年闲鱼双十一主互动是一个游戏化场景，具备互动复杂以及强运营诉求的特点，Kun能否在闲鱼双十一应用呢？
要做哪些准备
Kun之前的应用场景多是产品页面，页面交互相对简单，也不需要支持较强的运营能力。而双十一主互动和之前场景有较大差别，在双十一期间没有玩过闲鱼超级流通机的同学可以看下图体验下。整个页面分为两部分，上方区域是互动区域，用户通过做任务领取能量，收集能量共建风力发电机，页面上的元素会随着用户交互变化，在右上角还有一个入口点击进入摸鱼小游戏，用户快速点击屏幕模拟摸鱼行为进行PK；而下方区域则是运营区域，运营会根据双十一这段期间每天不同的主题搭建不同业务模块，涉及到促发布、免费送、回收、降价、商品列表等业务模块。
因此在双十一主互动应用核心要完善两方面的能力，上方互动区域涉及的互动以及动效相关能力，下方运营区域涉及的搭建以及营销相关能力。加上页面性能与用户体验，综合来看需要解决下面这三个问题：
1. Kun能否支撑双十一主互动需要的能力：Kun容器在Lottie、Audio以及部分营销活动常用能力上是缺失的，涉及客户端版本发布，需要提前补齐相关能力
2. 搭建平台能否支持搭建Kun页面：搭建目前只支持Web页面，Kun的渲染与模块与Web有差异，需要完善能够搭建Kun页面
3. 性能体验在营销互动场景下如何更好：页面包大小、加载性能、用户体验如何进行保障
问题如何解决
容器能力预言，面向失败设计
由于客户端存在发版时间周期，因此我们在最终双十一需求未明确之前就提前梳理了以往互动场景以及大促营销模块所需要的能力，对容器能力进行预言，提前将相关能力集成到客户端10月份之前的版本。从结果来看这样提前设计是行之有效的，后续虽然双十一主互动业务上有很多变化，但是所需要的能力基本上都具备了。
在另一方面也需要面向失败设计，如果Kun版本上线之后出问题如何能快速降级让用户访问Web版本。在降级能力上我们补全了依照页面降级、系统版本、手机型号降级的方式，并且支持通过App级配置下发以及页面Url参数识别两种方式，能从多个维度支持Kun页面降级。
魔鱼支持Kun搭建
闲鱼运营活动搭建基于魔鱼产研平台，之前只支持Web页面的搭建，整体研发与搭建流程如下所示：
1. 研发阶段：单个模块研发，发布时会将构建产物发布到CDN上，即每个模块都有对应的Web产物CDN JS
2. 搭建阶段：运营从模块库里挑选模块组装成页面，配置模块相关数据
3. 页面渲染阶段：页面访问会先请求魔鱼网关获取模块信息，根据模块信息会创建Script标签加载并执行模块的CDN JS；模块资源加载完之后将模块拼接在Web滚动容器（div）中渲染。这部分逻辑是通过页面渲染框架完成的，称之为Solution
对照Web页面的研发、搭建、渲染过程，要支持Kun页面的搭建需要进行以下改造：
1. 模块构建Kun单独端产物：模块需要再构建出一份Kun下的产物。实际上同一个模块的Web产物和Kun产物可以是一样的，但是部分扩展的组件与API在Web和Kun是有两份不同实现，为了包体积更小，我们需要针对Kun和Web进行分端构建，分端构建逻辑会在后面说明
2. 模块代码加载与执行：Web浏览器是通过创建Script标签的方式去加载与执行模块相关JS代码，Kun目前没有这种机制，所以Kun这里是利用Http Fetch API来加载JS代码，把代码加载到本地之后再通过eval方式执行，这样在内存里就有相关模块信息
3. 通过特殊容器包裹实现滚动能力：模块代码加载到内存里之后，需要把模块拼接到滚动容器里，这里就会存在Kun和Web比较大的一个差别。Web默认div就是滚动容器，像普通列表和瀑布流都是由div内的元素决定的；而在Kun下对应到Flutter只有特殊的容器才有滚动能力，不同的滚动能力是由滚动容器自身决定的，结合这次场景是将模块都放到kun-list中渲染，后续搭建平台针对kun-nested-scroll等其他滚动容器需要再设计
性能体验优化
性能优化主要聚焦于首屏加载性能，除了通用的ZCache（资源预加载）和Prefetch（接口预请求）之外，要达到的目标就是首屏资源更小、首屏出来更快。首先需要实现分端（Web&Kun）构建，Kun在设计上虽然整体参照阿里巴巴集团跨平台标准来对齐Web，但是部分扩展的组件以及API只支持Kun，在Web投放的话需要兼容判断在Web实现相应能力，例如kun-list这个Kun下的滚动组件，在Web下需要通过scroll div去实现相关能力。这就是为什么需要跨端物料这一层设计的原因，跨端物料会判断是Kun还是Web环境运行不同环境的代码，让上层业务开发无需感知分端差异。如果把Kun和Web产物混合到一起，代码量都会有些冗余，这是为什么需要分端构建出Kun和Web两端产物的原因。分端构建是这样实现的：
1. 代码通过window.kun判断分端逻辑
2. 通过AST分析，构建Kun代码时将window.kun替换成true
3. 利用webpack tree-shaking再将没有调用的代码剔除
实现分端构建之后，每个模块在Kun和Web构建的代码都精简了，接下来要处理的就是让首屏加载资源更少，次屏加载更快。再回到双十一主互动，可以明显区分首屏就是上方的互动区域，次屏就是下方的运营搭建区域。因此我们做了以下几个优化：
1. 将互动区域代码合并到页面渲染框架（Solution）中，这样页面渲染初始化的时候互动区域相关代码也同时执行，渲染相关UI
2. 做了上面第一步还不够，互动区域有些配置项还是需要依赖魔鱼网关接口的数据，因此渲染还需要等待接口返回。又做了近一步优化，将一些在双十一期间不太会变更的配置数据静态到代码中，互动区域UI渲染就不依赖接口返回，接口返回之后再将本地静态数据与远端动态配置merge之后更新相关UI
3. 魔鱼首屏网关接口数据返回也需要更快，因此对魔鱼接口进行改造，增加了单独配置首屏模块个数的能力，首屏接口只返回首屏需要的模块数据，次屏接口返回后续的模块数据
4. 由于互动区域模块已经内置到页面渲染框架（Solution）中了，次屏模块所依赖的一些公共模块已经在互动模块中加载了，这些依赖也不需要再加载了，因此在次屏模块的构建中剔除了这些互动模块已引入的依赖
最终效果怎么样
Kun线上性能还是非常不错的，80%首屏模块渲染完平均时间在600ms+，体感上基本都是直开。但是在这样有一定互动要求的场景下Kun依然存在一些稳定性问题，例如多个Lottie在循环播放的情况下内存水位一直在上涨，在iPhone高刷机器下CPU发热尤为严重。另外Kun虽然对比Web在首屏加载渲染上有非常大的优势，依然看到在渲染之后的交互体验上，Kun相比Web这个广泛应用的经典渲染容器并没有明显的优势，甚至在一些滚动体验上用户体感可能还有些差距。基于这些问题最终线上并没有全量投放Kun，然而在双十一主互动尝试Kun依然对我们有重大意义，在这样一个相比App产品链路更加偏营销互动的场景试验，我们完善了Kun自身和配套工程链路相关能力，同时也发现了Kun目前的边界以及不足，更加明确后续的优化方向。
后续在Kun的演进上，我们不仅仅会关注Web能力对齐以及增强更多新体验，同时会深耕Kun下的交互体验，让Kun能够接近并超越Web、Native等容器各自的优势，敬请期待。